Transmitting Map Data Images in a Limited Bandwidth Environment

ABSTRACT

Systems, methods, and apparatuses are provided for transmitting map data images in a limited bandwidth environment. In one embodiment, the method comprises determining or predicting, using a processor, a traffic condition or a weather condition for a location. The method further comprises developing at least one map image depicting the traffic condition or weather condition. The method further comprises encoding the map image in at least one payload. The method further comprises transmitting the at least one payload over-the-air to a navigation device.

FIELD

This application is a divisional under 35 U.S.C. § 121 and 37 C.F.R. §1.53(b) of U.S. patent application Ser. No. 14/502,400 filed Sep. 30,2014, the disclosure of which is incorporated herein by reference in itsentirety.

BACKGROUND

Representation and distribution of real time traffic information may bedata intensive. Mobile navigation devices (e.g., car or personalnavigation devices) may not be connected to or in communication with ahigh speed network for real time traffic updates. In certain cases, themobile navigation device may be bandwidth constrained. For example, themobile navigation device may only be able to receive and/or transmit upto a few kilobytes per second.

Current techniques designed to transmit traffic information to a mobilenavigation device having bandwidth constraints include radio datasystem-traffic message channel (RDS-TMC) based location referencing,Agora-C map based location referencing, or transport protocol expertsgroup (TPEG) methods. For example, a RDS-TMC system may use an AM or FMradio signal to send highly compressed bit streams of traffic data to acar or personal navigation system. Unfortunately, these currentstandards and techniques involve “coding up” as many of the roadsegments as possible in terms of pre-defined identifications or usinglatitude/longitude based representations. Therefore, there is acontinuing effort to provide improved systems and methods for providingtraffic data for a navigation system in a limited bandwidth environment.

SUMMARY

Systems, methods, and apparatuses are provided for transmitting digitalmap tiles and map data images in a limited bandwidth environment. In oneembodiment, the method comprises determining or predicting, using aprocessor, a traffic condition or a weather condition for a location.The method further comprises developing at least one map image depictingthe traffic condition or weather condition. The method further comprisesencoding the map image in at least one payload. The method furthercomprises transmitting the at least one payload over-the-air to anavigation device.

In another embodiment, the method comprises receiving, by a navigationdevice via an over-the-air AM or FM radio transmission signal, at leastone encoded map image, the at least one encoded map image comprising atraffic condition or a weather condition for a location. The methodfurther comprises decoding, using a processor of the navigation device,a decoded map image from the at least one encoded map image. The methodfurther comprises displaying at least a portion of the decoded map imageon a navigation device display.

Apparatuses are also provided for determining real time trafficconditions. In one embodiment, an apparatus comprises at least oneprocessor and at least one memory including computer program code forone or more programs, wherein the at least one memory and the computerprogram code configured to, with the at least one processor, cause theapparatus to at least perform: (1) determine or predict a trafficcondition or a weather condition for a location; (2) develop at leastone map image depicting the traffic condition or the weather condition;(3) encode the map image in at least one payload; and (4) transmit theat least one payload over-the-air to a navigation device.

In another embodiment, a navigation device comprises at least oneprocessor and at least one memory including computer program code forone or more programs, wherein the at least one memory and the computerprogram code configured to, with the at least one processor, cause thenavigation device to at least perform: (1) receive, via an over-the-airAM or FM radio transmission signal, at least one encoded map image, theat least one encoded map image comprising a traffic condition or weathercondition for a location; (2) decode a map image from the at least oneencoded map image; and (3) display at least a portion of the decoded mapimage on a navigation device screen.

BRIEF DESCRIPTION OF THE DRAWINGS

Exemplary embodiments are described herein with reference to thefollowing drawings.

FIGS. 1a and 1b illustrate examples of a traffic map image for ametropolitan area in daytime and nighttime settings, respectively.

FIG. 2 illustrates an example of formatted or encoded map data fortransmission to a navigation device.

FIG. 3 illustrates an example flowchart for transmitting map data imagesin a limited bandwidth environment.

FIG. 4 illustrates an example flowchart for receiving and processingencoded map data images in a limited bandwidth environment.

FIG. 5 illustrates an example system for a map data image managementsystem.

FIG. 6 illustrates an exemplary navigation device of the system of FIG.5.

FIG. 7 illustrates an exemplary server of the system of FIG. 5.

DETAILED DESCRIPTION

The following embodiments include systems, methods, and apparatuses fortransmitting digital map tiles and map data images (e.g., traffic dataimages) in a limited bandwidth environment. As used herein, a “limitedbandwidth environment” may refer to a mobile navigation device at leasttemporarily unable to receive or transmit data at a rate of at least 200kilobits/sec (i.e., third-generation (3G) standards). In certainembodiments, the limited bandwidth environment refers to a device atleast temporarily unable to receive and/or transmit data at a rate of atleast 100 kilobits/sec, 50 kilobits/sec, 25 kilobits/sec, or 10kilobits/sec. In certain embodiments, a limited bandwidth environmentrefers to a navigation device only able to receive and/or transmit dataat a rate of 1-100 kilobits/sec, 1-50 kilobits/sec, 1-25 kilobits/sec,1-10 kilobits/sec, or 5-10 kilobits/sec.

In certain embodiments, within the limited bandwidth environment, thenavigation device may be able to receive and transmit (i.e., two-waycommunication) “over-the-air.” Non-limiting examples of over-the-airtransmissions include AM or FM radio transmission signals or BluetoothUHF radio wave signals. In some embodiments, the navigation device isable to receive the over-the-air signal (e.g., AM or FM radiotransmission signal), but is not able to transmit a signal (i.e.,one-way communication).

In limited bandwidth situations, it may be difficult to transmit a largedata file or map data images (e.g., traffic or weather data) to anavigation device efficiently. Therefore, alternative systems,apparatuses, and methods are needed to provide map information in theselimited bandwidth settings. In certain embodiments, real-time map images(e.g., traffic or weather map images) may be developed and encoded. Theencoded map images may be transmitted to the navigation deviceover-the-air (e.g., using an AM or FM transmission). The encoded mapimages may be received by the navigation device and decoded. The decodedimages may then be displayed on the navigation device.

Such methods may allow for providing traffic information without havingto wirelessly transmit a large data file or image to the mobilenavigation device. Even low cost devices (e.g., devices without digitalmaps and little or no internet protocol connectivity) may be able to usedigitized AM/FM signals to gain access to real time traffic data in andaround the device's location.

Development of Map Images

Map images may be developed for any predefined map or road network, suchas a metropolitan area or city (e.g., a selected area of a city or aselected number of road segments within a city). In some embodiments,the map images may be developed for multiple areas or road segments inmultiple metropolitan areas or cities. The map images may be developedfor one or more of the following: traffic data, weather data, accidentdata, or “special event” data.

Traffic map images may be developed from a collection and analysis ofreal-time traffic data. Real-time traffic data may be collected atdefined intervals and the traffic map image updated based upon the mostrecent data collected. For example, real-time traffic map image may bedeveloped/updated every hour, 30 minutes, 15 minutes, 10 minutes, 5minutes, 2.5 minutes, 1 minute, etc.

In some embodiments, traffic map images may be developed from collectionand analysis of real-time, historical, and/or predictive traffic data.Historical traffic data for a specific road segment may be collected forspecified time segments or “epochs” to build a historical database. Insome embodiments, traffic data may be collected at various epochs of aweekday, weekend, holiday, etc. In some examples, the traffic data iscollected for every 5 minute epoch during rush hour and every 10 minuteepoch for “off-hour” times.

Traffic data may be collected for the average speed of the observedvehicles within the road segment, the frequency of vehicles, and/or theaverage heading of the vehicles. In certain embodiments, traffic datamay be collected from probe data extracted from devices (e.g., mobilephones) within the traveling vehicles, or from fixed monitoringlocations.

Based on the collection of traffic data, traffic map images may beformed from the calculated average speed, frequency, and/or heading foreach road or lane segment in real-time or at a determined historicaltime period. The traffic map images may be color-coded to depict thestate of traffic for each road segment in the predefined road network.In other embodiments, the images may be marked in varying forms ofdashed lines, etc. to depict the state of traffic. A machine-learningalgorithm may be used to define what color or dashed line to code theroad segment. In some embodiments, the color or dashed line may bedetermined based on a comparison between the average speed for the epochand the speed limit for the road segment in real-time.

In certain embodiments, the road segment in the traffic map image may becolor-coded green to represent traffic moving at a minimum percentage ofthe defined speed limit for the road segment. For example, the roadsegment may be color-coded green when the average speed is at 80% orgreater of the speed limit (i.e., 80+ km/hr where the speed limit is 100km/hr). Yellow color-codes may represent slower traffic conditions,representing traffic moving at a certain percentage of the defined speedlimit (e.g., average speeds of between 40% and 80% of the speed limit).Red color-codes may represent even slower moving traffic in comparisonto the defined speed limit for the road segment (e.g., average speedsless than 40% of the speed limit). Additional color-coding is alsopossible, such as a black color code designation for stand-still traffic(e.g., average speeds <5% of the speed limit), and orange forconstruction areas.

In certain embodiments, the road segment may include an individualcolor-code or dashed line for each lane of traffic (in each direction oftravel). In other embodiments, the road segment may include multiplecolor-codes or different forms of dashed lines representing fastermoving and slower moving zones within the road segment.

The number of overall traffic map images developed for the metropolitanlocation or city may be based on a number of different factorsincluding, but not limited to the overall area of the location/city, thearea of each traffic map image within the location/city, the number ofnode levels for the location/city (i.e., the number of sub-levels orzones within each level), the varying level of detail or types of roadsdepicted in the traffic map image (including whether or not theunderlying road network is depicted at all), and/or the number of uniquetraffic images for each level or sub-level.

In certain embodiments, multiple views of a single traffic map image maybe developed. For example, daytime and nighttime views of a traffic mapimage may be developed. A daytime view may include color-coded trafficsegments overlaying a substantially light (e.g., white) background,while a nighttime view may include color-coded traffic segmentsoverlaying a substantially dark (e.g., black) background for betterviewing in low ambient light conditions.

In a non-limiting embodiment, FIGS. 1a and 1b depict two different imageconfigurations of the same traffic pattern. In FIG. 1a , a daytime viewis depicted of a metropolitan area, wherein the traffic patterns areoverlaid on a road network. FIG. 1b represents the same traffic patternfor the metropolitan area overlaid on the road network for a selectednighttime view.

To the extent an end-user may be interested in an expanded perspectiveof traffic in the city, this may be accomplished in two or three nodelevels to represent the entire city, and one or two zoomed in,sub-levels or nodes within the city. To the extent more narrowed orzoomed in views of a location are desired, additional sub-levels ornodes may be developed.

In addition to the development of traffic map images for a metropolitanarea, weather map images may additionally or alternatively be developedfrom a collection and analysis of real-time weather data. Weather mapimages may be developed based on rain, snow, ice, etc. within the maparea. Similar to the traffic map images, the weather map images may becolor-coded to depict the state of weather for the map area. Forexample, the weather map image may be color coded based on the real-timeradar intensity of the rain/snow precipitation (e.g., very light rain orsnow is depicted in light blue, moderate rain is depicted in green,severe rain is depicted in red).

Encoding the Map Image Data

In limited bandwidth connectivity situations, current traffic and/orweather map image data may be encoded and transmitted to the navigationdevice without sending large amounts of data over-the-air. Instead, mapimages may be encoded for transmission in low bandwidth situations(e.g., situations wherein low sized images are readily transmittable).The map image data (e.g., traffic and/or weather data) may be encoded inASCII, UTF-8, ISO-8859-1, or XML, for example. In one particularembodiment, the map image data is encoded in ASCII format.

In certain embodiments, larger developed map image files (e.g., a single64 kilobyte (KB) image file) may be broken up into smaller data files tobe transmitted in multiple payloads. In certain embodiments, eachpayload of the multiple payloads is less than or approximately 1, 2, 4,8, or 16 kilobytes. In one particular embodiment, each payload isapproximately 4 kilobytes. The over-the-air transmission may beformatted or encoded to include data in a specific order (includingimage data transmitted in multiple payloads).

FIG. 2 provides a non-limiting embodiment of the format of the encodedmap data. For example, in FIG. 2, the transmission may include a contentheader with the content data. The content header may compriseinformation such as network caller identification (NCID) and versioninformation, protocol version information, beginning sequence number andend sequence number, and message length. Each segment of the contentheader may comprise a limited amount of data space (e.g., 1 or 2 byteseach). In the transmission, the content header may be followed orpreceded by the content data. The content data may include the lowstorage sized encoded map image, along with additional data information(discussed in greater detail below).

In certain embodiments, the content header and content data may bebookended on the front end and back end by a buffer header and a buffertrailer, respectively. In some embodiments, the buffer header maycomprise service sync (start) information and/or a buffer length. Thebuffer trailer may comprise a cyclic redundancy check (CRC) and/orservice sync (end) information. Like the content header information,each component of the buffer header and trailer may comprise a limitedamount of data space (e.g., 1 or 2 bytes each).

In certain embodiments, a plurality of content headers and content data(e.g., more than one map image) may be included between the bufferheader and buffer trailer. Such a flexible payload approach (i.e., oneor more content buffers) instead of a fixed length payload allows forthe distribution channel to optimize and control the type of images thatcan be streamed to the device.

As mentioned above, the content data includes the map image itself, or afraction of the overall map image to the extent the image is broken upinto multiple payloads. The map image may be encoded and stored as animage byte stream. The image may be stored in .jpeg or .png format.Other image format options are also available.

In addition to the encoded image, the content data may include variousfields of information included in the overall transmission message. Forexample, in one field, the content data may include date and timeinformation associated with the image data. The time stamp may beexpressed in coordinated universal time (UTC) format in 33 bits of data(e.g., expressed as YYYYYYYMMMMDDDDDhhhhhmmmmmmssssss).

The content data may also comprise information regarding the number ofimages included with the transmission (expressed as an integer value).The content data may also include latitude and longitude information toform a bounding box for each image. For example, the content data mayinclude information regarding one corner of the bounding box (e.g., theSouthwest latitude and longitude values), as well as the opposite cornerof the bounding box (e.g., the Northeast latitude and longitude values).The latitude information may be expressed as an integer (e.g., 0=N,1=S), followed by the value associated with the geographic coordinatefrom the equator (e.g., three digits for the degrees, and five digitsfor the decimal degrees). The longitude information may also beexpressed as an integer (e.g., 0=E, 1=W), followed by the valueassociated with the geographic coordinate from the prime meridian (e.g.,three digits for the degrees, and five digits for the decimal degrees).

The content data may also include information regarding the length of animage description (e.g., an integer value indicating the length of thedescription where the value ‘0’ indicates no description). The imagedescription may also be provided, to the extent one exists. Thedescription may be encoded in UTF-8 characters and comprise between 1and 255 bytes.

The content data may also include information regarding the type ofencoded image. For example, an image type value of ‘0’ may refer to acompressed .jpeg image. A value of ‘1’ may refer to a .png image. Valuesof ‘2’, ‘3’, etc. may be saved for future use for different types ofencoded images.

The content data may include information regarding the view type of theencoded image (such as whether the encoded image represents a downtownview, a view of an entire metropolitan area, or a view of a segment of acity).

The content data may also include a preferred pixel per inch (PPI) valueupon decoding the image. The preferred PPI value may be stored as aninteger representing the preferred value for displaying the imageclearly on the navigation device.

The content data may include the size of the image (in bytes).

To the extent more than one image is being encoded for transmission, theimage data is repeated for each additional image (e.g.,latitude/longitude data, image description, image type, image bytestream, etc.).

One embodiment of the overall formatted content data is provided in thetable below. As shown in the table, certain segments are reserved forfuture use to potentially encode and include additional information inthe transmission.

TABLE Map Image Transmission Message Format Order Size Field NameDescription 1 7 bits Reserved for future use (“RFU”) 2 33 bits Date/TimeTime stamp expressed in UTC. 33 bits used as:YYYYYYYMMMMDDDDDhhhhhmmmmmmssssss 3 1 byte Number of images Integervalue for number of images embedded. 4 26 bits Southwest SouthwestLatitude of the bounding box for the Latitude next image. Expressed asInteger for sign (0 = N, 1 = S), then degrees and decimal degrees tofive decimal digits. Degrees value are three digits, decimal part isfive digits. 5 26 bits Southwest Southwest Longitude of the bounding boxfor the Longitude next image. Expressed as Integer for sign (0 = E, 1 =W), then degrees and decimal degrees to five decimal digits. Degreesvalue are three digits, decimal part is five digits. 6 26 bits NortheastLatitude Northeast Latitude of the bounding box for the next image. (AsOrder 4). 7 26 bits Northeast Northeast Longitude of the bounding boxfor the Longitude next image. (as Order 5). 8 1 byte Length of ImageInteger value indicating Length of Image Description Description. Value= 0 means there is no description. 9 1 . . . 255 bytes Image DescriptionDescription of the next image. UTF-8 characters. (UTF-8) 10 4 bitsReserved for future use (“RFU”) 11 2 bits Image Type 0 = jpg, 1 = png, 2= RFU, 3 = RFU 12 2 bits View Type 0 = Downtown View, 1 = Suburban View2 = RFU 3 = RFU 13 2 bytes Preferred Display Integer value for PreferredPixel per inch value to PPI (Pixels) display the picture clearly 14 2bytes Size of Image (in Integer value indicating Number of Bytes in theBytes) next image byte stream 15  1 . . . n bytes Image byte Stream Bytestream of the image. Variable length 16 Repeating fields from 4 to 13for each additional image

Transmitting the Encoded Map Image Data

Following the formatting and encoding of the map image data, a serverprocessor may instruct the transmitter to relay the encoded image(s) inan over-the-air signal (e.g., an AM or FM radio signal) to a receiverconnected to the navigation device. In certain embodiments, multiplepayloads of encoded image data are transmitted. In such cases, themultiple payloads may be transmitted in a specific order for decoding.

In situations with limited connectivity and one-way communicationbetween a transmitter and the navigation device, the navigation devicemay be able to receive transmissions from a transmitter. With two-waycommunication between a transmitter and server-side receiver and thenavigation device, the navigation device may be able to receivetransmissions from a transmitter and also send transmissions back to areceiver. For example, the navigation device may be able to send signalsto the receiver. The navigation device transmission signals may includeinformation regarding its current geographic position or user inputinformation such as the level of detail or zoom level requested. Inturn, the transmitter/receiver may relay the navigation deviceinformation for processing. Such communication from the navigationdevice may assist in determining the specific transmission signal toreturn to the navigation device.

In certain embodiments, the transmitter/receiver may be in communicationwith a network having access to real-time or current traffic conditions.The transmitter/receiver and network may also be in communication with aprocessor capable of running predictive algorithms to determine trafficconditions for inclement weather, traffic accidents, or constructionscenarios. For example, the predictive algorithm may be able tocalculate what the road traffic may look like in the future based on theweather or a recent traffic accident, and be able to determine whattraffic map image to generate.

Receiving and Decoding the Map Image Data

After the navigation device has received a signal from an externaltransmitter with the encoded map image(s), the navigation device maythen decode the map image(s).

In certain embodiments, based on the encoded map image data describedabove, a receiver connected to a navigation device may be able to ensurethat complete frames of image data are received. Additionally, thenavigation device receiver may be able to confirm that complete buffersof content are received. Further, the formatted or encoded data mayallow the navigation device receiver to decode and reassemble the data.

In certain embodiments, the navigation device may validate and decodethe received transmission by finding the start of the service sync inthe buffer header. Additionally, the navigation device may validate thebuffer length and the cyclic redundancy check value.

Further, for each content data transmitted, the decoding process mayinclude: (1) storing the sequence number and end sequence number, (2)storing the message length, (3) copying the message length bytes to adata buffer, and (4) using the sequence number to place the image datain the correct position in the received data stream.

In certain embodiments, if the data is out of order, or if the CRCvalidation fails, the content data should be dropped or rejected by thenavigation device receiver.

Displaying the Decoded Map Image

After the navigation device has decoded the transmitted map image datafrom the external transmitter, the navigation device may display adecoded image on the navigation device or a display in communicationwith the navigation device.

In certain embodiments, more than one image may be decoded. In thesesituations, the end-user or the navigation device processor maydetermine or select which image to display. For example, the end-user orthe navigation device processor may select between a view of the entiremetropolitan area versus a view of the downtown area. In otherembodiments, the selection may include how the image is displayed (e.g.,a daytime view or a nighttime view of traffic conditions, a daytime or anighttime view of weather conditions in the area). In some embodiments,the selected view may be determined by a navigation device processorwithout user input. The processor may determine which image or portionof an image to display based upon the geographic location of thenavigation device (e.g., GPS location). The processor may also determinewhich image or portion of an image to display (e.g., a daytime image ora nighttime image) based on the time of day and time of year. Forexample, if the navigation device processor is aware that the time is9:00 p.m. in Chicago in December, the processor may select a nighttimeimage to be displayed (if available) on the navigation device screen asa default without end-user input.

In yet other embodiments, the end-user or navigation device processormay adjust the view of a particular map image or combination of mapimages to center the displayed image at the location of theend-user/navigation device. For example, the navigation device may beable to use a global positioning system locally on the device todetermine whether the navigation device is located on a highway or localroad, and which map image(s) to display. In other embodiments, theend-user may be able to provide input to the navigation device regardingthe location of the navigation device, the level of detail requested, orthe zoom level requested.

Repeating/Refreshing the Map Reporting

The process of (1) determining the map condition (e.g., real-timetraffic or weather), (2) encoding the map image data, (3) transmittingthe encoded map image data to a navigation device, (4) decoding theimage data, and (5) displaying the decoded map image data may berepeated at set or variable intervals of time. In situations of one-wayor two-way limited bandwidth communication, encoded map image data maybe relayed to the navigation device continuously, at set times, or atrandom times only where the traffic condition has changed from the lastreporting.

As discussed above, advantages of these systems, apparatuses, andmethods include that even low cost devices (e.g., devices withoutdigital maps and little or no internet protocol connectivity) may beable to use digitized AM/FM signals to gain access to real time trafficdata in and around the device's location. Additionally, the transmissionof a flexible payload approach (i.e., one or more content buffers)instead of a fixed length payload allows for the distribution channel tooptimize and control the type of images that can be streamed to thedevice. Further, the CRC check allows for retention of quality of imagesthat are transmitted over-the-air. Also, the process allows forflexibility in terms of how the map level of images may be combined orseparated with traffic data related colors that are rendered on the roadsegments. The encoding and decoding process is also agnostic to thesize, format and type of images. For example, one implementation couldsend ten different lower quality, compressed .jpeg images to representmore complex traffic in cities such as New York, compared with just twoimages for Kansas City (where traffic density may not be as high).Additionally, as mentioned above, the encoding and decoding process maybe performed for additional or alternative information such as weatherdata, accidents, or other “special events” that may be highlighted onthe map image and transmitted in a similar fashion.

FIG. 3 illustrates an example flowchart for transmitting map data imagesin a limited bandwidth environment. The process of the flowchart may beperformed by a map database server and its processor and/or navigationdevice and its processor. Alternatively, another device may beconfigured to perform one or more of the following acts. Additional,fewer, or different acts may be included.

At act S101, a traffic condition or a weather condition is determined orpredicted using a map database processor. The traffic or weathercondition for a location may be determined based a collection andanalysis of real-time traffic or weather data. Alternatively oradditionally, the traffic or weather condition may be determined from acollection and analysis of real-time, historical, and/or predictivetraffic or weather data.

At act S103, at least one map image may be developed from the traffic orweather data. A traffic map image may include road segments that arecolor-coded or marked with dashed lines to represent the type of trafficpattern present on the road segment in each of the images.

At act S105, the at least one map image is encoded in at least onepayload for transmission. For example, larger developed map image filesmay be broken up into smaller data files to be transmitted in multiplepayloads. The map image may be encoded with content header informationsuch as a beginning sequence number and an end sequence number for eachimage segment or payload. The map image may also be encoded with otherinformation such as a timestamp, a total number of images in thetransmission, a bounding box (latitude/longitude coordinates) for theimage(s), an image description, an image type identifier or value, animage view identifier, a preferred pixel per inch value for the decodedimage, and/or a size of the image.

At act S107, following the encoding of the at least one map image, eachencoded image may be transmitted in at least one payload over-the-air toa navigation device for further processing. The transmission may occurvia an AM or FM signal. Further, each transmission may be monitored tobe below a threshold size for processing in a limited bandwidthenvironment.

FIG. 4 illustrates an example flowchart for receiving and processingencoded map data images in a limited bandwidth environment. The processof the flowchart may be performed by a navigation device and itsprocessor and/or a server and its processor. Alternatively, anotherdevice may be configured to perform one or more of the following acts.Additional, fewer, or different acts may be included.

At act S201, an AM or FM transmission signal is received by a navigationdevice receiver. The signal comprises at least one encoded map imagewith traffic or weather information. In certain embodiments, the atleast encoded one map image is received in a plurality of payloads,wherein each payload of the plurality of payloads comprises a beginningsequence number and an end sequence number.

At act S203, each transmitted map image may be decoded by a server orprocessor in communication with the navigation device. The decoding maycomprise combining a plurality of payloads in order of sequencingnumbers of each payload to provide the decoded map image.

At act S205, at least a portion of the decoded map image may bedisplayed on a navigation device display. In certain embodiments, theend-user or the navigation device processor may determine or selectwhich image to display or which portion of an image to display.

As discussed above, transmitting and receiving map data in a limitedbandwidth environment may be performed by a navigation device and itsprocessor and/or a server and its processor. FIG. 5 illustrates oneembodiment of a map data image management system 120. The system 120 mayinclude a map developer system 121, a navigation device 122, aworkstation 128, and a network 127. Additional, different, or fewercomponents may be provided.

The navigation device 122 may be a personal navigation device (“PND”), aportable navigation device smart phone, a mobile phone, a personaldigital assistant (“PDA”), a tablet computer, a notebook computer,and/or any other known or later developed mobile device or personalcomputer. Non-limiting embodiments of navigation devices may alsoinclude RDS devices, mobile phone devices, or car navigation devicessuch as Garmin or TomTom.

The map developer system 121 includes a server 125 and a server database123. The developer system 121 may include computer systems and networksof a system operator such as HERE, NAVTEQ, or Nokia Corporation. Theserver database 123 is configured to store traffic map images developedfrom historical traffic data or predictive traffic data. The database123 is also configured to store identification keys associated with thetraffic map images.

The developer system 121, the workstation 128, and the navigation device122 are coupled with the network 127. The phrase “coupled with” isdefined to mean directly connected to or indirectly connected throughone or more intermediate components. Such intermediate components mayinclude hardware and/or software-based components. In certainembodiments, the navigation device 122 may be coupled with the networkthrough a radio transmitter/receiver 130, which may transmit“over-the-air” radio transmission signals (e.g., an AM or FM signal) tothe navigation device 122. In some embodiments, the radiotransmitter/receiver 130 may receive transmission signals from thenavigation device 122.

The workstation 128 may be a general purpose computer includingprogramming specialized for providing input to the server 125. Forexample, the workstation 128 may provide settings for the server 125.The settings may include a value for the predetermined interval that theserver 125 requests the navigation device 122 to relay currentgeographic locations. The workstation 128 may be used to enter dataindicative of GPS accuracy to the database 123. The workstation 128 mayinclude at least a memory, a processor, and a communication interface.

FIG. 6 illustrates an exemplary navigation device 122 of the system ofFIG. 5. The navigation device 122 includes a processor 200, a memory204, an input device 203, a communication interface 205, positioncircuitry 207, and a display 211. Additional, different, or fewercomponents are possible for the mobile device/personal computer 122. Incertain embodiments, the communication interface 205 of the navigationdevice 122 comprises an AM and/or FM radio receiver. The receiver may bea high-definition radio receiver.

The processor 200 may be configured to receive data indicative of thelocation of the navigation device 122 from the position circuitry 207.The positioning circuitry 207, which is an example of a positioningsystem, is configured to determine a geographic position of thenavigation device 122. The positioning system may also include areceiver and correlation chip to obtain a GPS signal. The positioningcircuitry may include an identifier of a model of the positioningcircuitry 207. The processor 200 may access the identifier and query adatabase or a website to retrieve the accuracy of the positioningcircuitry 207 based on the identifier. The positioning circuitry 207 mayinclude a memory or setting indicative of the accuracy of thepositioning circuitry.

FIG. 7 illustrates an exemplary server 125 of the system of FIG. 5. Theserver 125 includes a processor 300, a communication interface 305, anda memory 301. The server 125 may be coupled to a database 123 and aworkstation 128. The workstation 128 may be used as an input device forthe server 125. In addition, the communication interface 305 is an inputdevice for the server 125. In certain embodiments, the communicationinterface 305 may receive data indicative of use inputs made via theworkstation 128 or the navigation device 122.

The navigation device processor 200 and/or the server processor 300 mayinclude a general processor, digital signal processor, an applicationspecific integrated circuit (ASIC), field programmable gate array(FPGA), analog circuit, digital circuit, combinations thereof, or othernow known or later developed processor. The navigation device processor200 and/or the server processor 300 may be a single device orcombinations of devices, such as associated with a network, distributedprocessing, or cloud computing.

The navigation device processor 200 and/or the server processor 300 mayalso be configured to cause an apparatus to at least perform at leastone of traffic map image retrieval methods described above. For example,the navigation device processor 200 may be configured to perform theprocess: (1) receive, via an over-the-air AM or FM radio transmissionsignal, at least one encoded map image, the at least one encoded mapimage comprising a traffic condition or weather condition for alocation; (2) decode a map image from the at least one encoded mapimage; and (3) display at least a portion of the decoded map image on anavigation device screen.

In another embodiment, the server processor 300 may be configured toperform the process: (1) determine or predict a traffic condition or aweather condition for a location; (2) develop at least one map imagedepicting the traffic condition or the weather condition; (3) encode themap image in at least one payload; and (4) transmit the at least onepayload over-the-air to a navigation device.

The memory 204 and/or memory 301 may be a volatile memory or anon-volatile memory. The memory 204 and/or memory 301 may include one ormore of a read only memory (ROM), random access memory (RAM), a flashmemory, an electronic erasable program read only memory (EEPROM), orother type of memory. The memory 204 and/or memory 301 may be removablefrom the navigation device 122, such as a secure digital (SD) memorycard.

The communication interface 205 and/or communication interface 305 mayinclude any operable connection. An operable connection may be one inwhich signals, physical communications, and/or logical communicationsmay be sent and/or received. An operable connection may include aphysical interface, an electrical interface, and/or a data interface.The communication interface 205 and/or communication interface 305provides for wireless and/or wired communications in any now known orlater developed format.

In certain embodiments, receiving and decoding of the encoded map imageon the navigation device may be used to provide functions for anautonomous vehicle. An autonomous vehicle is self-driving and may bereferred to as a robot vehicle or an automated vehicle. The autonomousvehicle may include passengers but no driver is necessary. Thenavigation device 122 or another computer system in communication withthe navigation device 122 may include instructions for routing thevehicle or operating the vehicle. An estimated travel time may becalculated based on the traffic map data and a route may be chosen basedon the estimate travel time. The computing system may generate drivingcommands for steering the vehicle, shifting gears, increasing anddecreasing the throttle, and braking. The computing system may generateauxiliary commands for controlling the headlights, turn signals,windshield wipers, defrost, or other auxiliary functions not directlyrelated to the movement of the vehicle.

The autonomous vehicle may include sensors for identifying thesurrounding and location of the car. The sensors may include GPS, lightdetection and ranging (LIDAR), radar, and cameras for computer vision.Proximity sensors may aid in parking the vehicle. The proximity sensorsmay detect the curb or adjacent vehicles. The autonomous vehicle mayoptically track and follow lane markings or guide markings on the road.

In the above described embodiments, the network 127 may include wirednetworks, wireless networks, or combinations thereof. The wirelessnetwork may be a cellular telephone network, an 802.11, 802.16, 802.20,or WiMax network. Further, the network 127 may be a public network, suchas the Internet, a private network, such as an intranet, or combinationsthereof, and may utilize a variety of networking protocols now availableor later developed including, but not limited to TCP/IP based networkingprotocols. In certain embodiments, the network may be in communicationwith a radio transmitter/receiver 130 that produces and/or receives AMor FM signal to communicate with the navigation device 122.

While the non-transitory computer-readable medium is described to be asingle medium, the term “computer-readable medium” includes a singlemedium or multiple media, such as a centralized or distributed database,and/or associated caches and servers that store one or more sets ofinstructions. The term “computer-readable medium” shall also include anymedium that is capable of storing, encoding or carrying a set ofinstructions for execution by a processor or that cause a computersystem to perform any one or more of the methods or operations disclosedherein.

In a particular non-limiting, exemplary embodiment, thecomputer-readable medium can include a solid-state memory such as amemory card or other package that houses one or more non-volatileread-only memories. Further, the computer-readable medium can be arandom access memory or other volatile re-writable memory. Additionally,the computer-readable medium can include a magneto-optical or opticalmedium, such as a disk or tapes or other storage device to capturecarrier wave signals such as a signal communicated over a transmissionmedium. A digital file attachment to an e-mail or other self-containedinformation archive or set of archives may be considered a distributionmedium that is a tangible storage medium. Accordingly, the disclosure isconsidered to include any one or more of a computer-readable medium or adistribution medium and other equivalents and successor media, in whichdata or instructions may be stored.

In an alternative embodiment, dedicated hardware implementations, suchas application specific integrated circuits, programmable logic arraysand other hardware devices, can be constructed to implement one or moreof the methods described herein. Applications that may include theapparatus and systems of various embodiments can broadly include avariety of electronic and computer systems. One or more embodimentsdescribed herein may implement functions using two or more specificinterconnected hardware modules or devices with related control and datasignals that can be communicated between and through the modules, or asportions of an application-specific integrated circuit. Accordingly, thepresent system encompasses software, firmware, and hardwareimplementations.

In accordance with various embodiments of the present disclosure, themethods described herein may be implemented by software programsexecutable by a computer system. Further, in an exemplary, non-limitedembodiment, implementations can include distributed processing,component/object distributed processing, and parallel processing.Alternatively, virtual computer system processing can be constructed toimplement one or more of the methods or functionality as describedherein.

Although the present specification describes components and functionsthat may be implemented in particular embodiments with reference toparticular standards and protocols, the invention is not limited to suchstandards and protocols. For example, standards for Internet and otherpacket switched network transmission (e.g., TCP/IP, UDP/IP, HTML, HTTP,HTTPS) represent examples of the state of the art. Such standards areperiodically superseded by faster or more efficient equivalents havingessentially the same functions. Accordingly, replacement standards andprotocols having the same or similar functions as those disclosed hereinare considered equivalents thereof.

A computer program (also known as a program, software, softwareapplication, script, or code) can be written in any form of programminglanguage, including compiled or interpreted languages, and it can bedeployed in any form, including as a standalone program or as a module,component, subroutine, or other unit suitable for use in a computingenvironment. A computer program does not necessarily correspond to afile in a file system. A program can be stored in a portion of a filethat holds other programs or data (e.g., one or more scripts stored in amarkup language document), in a single file dedicated to the program inquestion, or in multiple coordinated files (e.g., files that store oneor more modules, sub programs, or portions of code). A computer programcan be deployed to be executed on one computer or on multiple computersthat are located at one site or distributed across multiple sites andinterconnected by a communication network.

The processes and logic flows described in this specification can beperformed by one or more programmable processors executing one or morecomputer programs to perform functions by operating on input data andgenerating output. The processes and logic flows can also be performedby, and apparatus can also be implemented as, special purpose logiccircuitry, e.g., an FPGA (field programmable gate array) or an ASIC(application specific integrated circuit).

As used in this application, the term “circuitry” or “circuit” refers toall of the following: (a) hardware-only circuit implementations (such asimplementations in only analog and/or digital circuitry) and (b) tocombinations of circuits and software (and/or firmware), such as (asapplicable): (i) to a combination of processor(s) or (ii) to portions ofprocessor(s)/software (including digital signal processor(s)), software,and memory(ies) that work together to cause an apparatus, such as amobile phone or server, to perform various functions) and (c) tocircuits, such as a microprocessor(s) or a portion of amicroprocessor(s), that require software or firmware for operation, evenif the software or firmware is not physically present.

This definition of “circuitry” applies to all uses of this term in thisapplication, including in any claims. As a further example, as used inthis application, the term “circuitry” would also cover animplementation of merely a processor (or multiple processors) or portionof a processor and its (or their) accompanying software and/or firmware.The term “circuitry” would also cover, for example and if applicable tothe particular claim element, a baseband integrated circuit orapplications processor integrated circuit for a mobile phone or asimilar integrated circuit in server, a cellular network device, orother network device.

Processors suitable for the execution of a computer program include, byway of example, both general and special purpose microprocessors, andanyone or more processors of any kind of digital computer. Generally, aprocessor receives instructions and data from a read only memory or arandom access memory or both. The essential elements of a computer are aprocessor for performing instructions and one or more memory devices forstoring instructions and data. Generally, a computer also includes, orbe operatively coupled to receive data from or transfer data to, orboth, one or more mass storage devices for storing data, e.g., magnetic,magneto optical disks, or optical disks. However, a computer need nothave such devices. Moreover, a computer can be embedded in anotherdevice, e.g., a mobile telephone, a personal digital assistant (PDA), amobile audio player, a Global Positioning System (GPS) receiver, to namejust a few. Computer readable media suitable for storing computerprogram instructions and data include all forms of non-volatile memory,media and memory devices, including by way of example semiconductormemory devices, e.g., E PROM, EEPROM, and flash memory devices; magneticdisks, e.g., internal hard disks or removable disks; magneto opticaldisks; and CD ROM and DVD-ROM disks. The processor and the memory can besupplemented by, or incorporated in, special purpose logic circuitry.

To provide for interaction with a user, embodiments of the subjectmatter described in this specification can be implemented on a devicehaving a display, e.g., a CRT (cathode ray tube) or LCD (liquid crystaldisplay) monitor, for displaying information to the user and a keyboardand a pointing device, e.g., a mouse or a trackball, by which the usercan provide input to the computer. Other kinds of devices can be used toprovide for interaction with a user as well; for example, feedbackprovided to the user can be any form of sensory feedback, e.g., visualfeedback, auditory feedback, or tactile feedback; and input from theuser can be received in any form, including acoustic, speech, or tactileinput.

Embodiments of the subject matter described in this specification can beimplemented in a computing system that includes a back end component,e.g., as a data server, or that includes a middleware component, e.g.,an application server, or that includes a front end component, e.g., aclient computer having a graphical user interface or a Web browserthrough which a user can interact with an implementation of the subjectmatter described in this specification, or any combination of one ormore such back end, middleware, or front end components. The componentsof the system can be interconnected by any form or medium of digitaldata communication, e.g., a communication network. Examples ofcommunication networks include a local area network (“LAN”) and a widearea network (“WAN”), e.g., the Internet.

The computing system can include clients and servers. A client andserver are generally remote from each other and typically interactthrough a communication network. The relationship of client and serverarises by virtue of computer programs running on the respectivecomputers and having a client-server relationship to each other.

The illustrations of the embodiments described herein are intended toprovide a general understanding of the structure of the variousembodiments. The illustrations are not intended to serve as a completedescription of all of the elements and features of apparatus and systemsthat utilize the structures or methods described herein. Many otherembodiments may be apparent to those of skill in the art upon reviewingthe disclosure. Other embodiments may be utilized and derived from thedisclosure, such that structural and logical substitutions and changesmay be made without departing from the scope of the disclosure.Additionally, the illustrations are merely representational and may notbe drawn to scale. Certain proportions within the illustrations may beexaggerated, while other proportions may be minimized. Accordingly, thedisclosure and the figures are to be regarded as illustrative ratherthan restrictive.

While this specification contains many specifics, these should not beconstrued as limitations on the scope of the invention or of what may beclaimed, but rather as descriptions of features specific to particularembodiments of the invention. Certain features that are described inthis specification in the context of separate embodiments can also beimplemented in combination in a single embodiment. Conversely, variousfeatures that are described in the context of a single embodiment canalso be implemented in multiple embodiments separately or in anysuitable sub-combination. Moreover, although features may be describedabove as acting in certain combinations and even initially claimed assuch, one or more features from a claimed combination can in some casesbe excised from the combination, and the claimed combination may bedirected to a sub-combination or variation of a sub-combination.

Similarly, while operations are depicted in the drawings and describedherein in a particular order, this should not be understood as requiringthat such operations be performed in the particular order shown or insequential order, or that all illustrated operations be performed, toachieve desirable results. In certain circumstances, multitasking andparallel processing may be advantageous. Moreover, the separation ofvarious system components in the embodiments described above should notbe understood as requiring such separation in all embodiments, and itshould be understood that the described program components and systemscan generally be integrated together in a single software product orpackaged into multiple software products.

One or more embodiments of the disclosure may be referred to herein,individually and/or collectively, by the term “invention” merely forconvenience and without intending to voluntarily limit the scope of thisapplication to any particular invention or inventive concept. Moreover,although specific embodiments have been illustrated and describedherein, it should be appreciated that any subsequent arrangementdesigned to achieve the same or similar purpose may be substituted forthe specific embodiments shown. This disclosure is intended to cover anyand all subsequent adaptations or variations of various embodiments.Combinations of the above embodiments, and other embodiments notspecifically described herein, are apparent to those of skill in the artupon reviewing the description.

The Abstract of the Disclosure is provided to comply with 37 C.F.R. §1.72(b) and is submitted with the understanding that it will not be usedto interpret or limit the scope or meaning of the claims. In addition,in the foregoing Detailed Description, various features may be groupedtogether or described in a single embodiment for the purpose ofstreamlining the disclosure. This disclosure is not to be interpreted asreflecting an intention that the claimed embodiments require morefeatures than are expressly recited in each claim. Rather, as thefollowing claims reflect, inventive subject matter may be directed toless than all of the features of any of the disclosed embodiments. Thus,the following claims are incorporated into the Detailed Description,with each claim standing on its own as defining separately claimedsubject matter.

It is intended that the foregoing detailed description be regarded asillustrative rather than limiting and that it is understood that thefollowing claims including all equivalents are intended to define thescope of the invention. The claims should not be read as limited to thedescribed order or elements unless stated to that effect. Therefore, allembodiments that come within the scope and spirit of the followingclaims and equivalents thereto are claimed as the invention.

What is claimed is:
 1. A method comprising: receiving, by a navigationdevice via an over-the-air AM or FM radio transmission signal, at leastone encoded map image, the at least one encoded map image comprising atraffic condition or a weather condition for a location; decoding, usinga processor of the navigation device, a decoded map image from the atleast one encoded map image; and displaying at least a portion of thedecoded map image on a navigation device display.
 2. The method of claim1, wherein the at least encoded one map image is received in a pluralityof payloads, wherein each payload of the plurality of payloads comprisesa beginning sequence number and an end sequence number.
 3. The method ofclaim 2, wherein the decoding comprises: combining the plurality ofpayloads in order of sequencing numbers of each payload to provide thedecoded map image.
 4. The method of claim 1, wherein the at least oneencoded map image is encoded with buffer header and buffer trailer data,wherein the buffer trailer data includes cyclic redundancy check data.5. The method of claim 4, further comprising: validating a quality ofthe at least one encoded map image using the cyclic redundancy checkdata.
 6. The method of claim 4, further comprising: rejecting the atleast one encoded map image by the navigation device if the cyclicvalidating fails.
 7. The method of claim 1, wherein over-the-air AM orFM radio transmission signal includes a radio data system-trafficmessage channel.
 8. The method of claim 1, wherein the at least oneencoded map image at a predetermined time interval.
 9. The method ofclaim 1, wherein the at least one encoded map image includes apredetermined number of image files.
 10. The method of claim 9, whereinthe predetermined number is selected according to an area of thelocation, a number of node levels for the location, types of roadsincluded in the at least one encoded map image, or a number of uniquetraffic images for each level or sub-level.
 11. A navigation devicecomprising: at least one processor; and at least one memory includingcomputer program code for one or more programs; the at least one memoryand the computer program code configured to, with the at least oneprocessor, cause the navigation device to at least perform: receive, viaan over-the-air AM or FM radio transmission signal, at least one encodedmap image, the at least one encoded map image comprising a trafficcondition or a weather condition for a location; decode a map image fromthe at least one encoded map image; and display at least a portion ofthe decoded map image on a navigation device screen.
 12. The navigationdevice of claim 11, wherein the at least encoded one map image isreceived in a plurality of payloads, wherein each payload of theplurality of payloads comprises a beginning sequence number and an endsequence number.
 13. The navigation device of claim 12, wherein thedecoding comprises: combining the plurality of payloads in order ofsequencing numbers of each payload to provide the decoded map image. 14.The navigation device of claim 11, wherein the at least one encoded mapimage is encoded with buffer header and buffer trailer data, wherein thebuffer trailer data includes cyclic redundancy check data.
 15. Thenavigation device of claim 14, wherein the at least one memory and thecomputer program code are configured to cause the navigation device tofurther perform: validate a quality of the at least one encoded mapimage using the cyclic redundancy check data.
 16. The navigation deviceof claim 15, wherein the at least one memory and the computer programcode are configured to cause the navigation device to further perform:reject the at least one encoded map image by the navigation device ifthe cyclic validating fails.
 17. The navigation device of claim 15,wherein over-the-air AM or FM radio transmission signal includes a radiodata system-traffic message channel.
 18. A non-transitory computerreadable medium including instructions that when executed are configuredto perform: receiving, by a mobile device via a transmission signal, atleast one encoded map image comprising a transient condition for alocation; decoding, using the mobile device, a decoded map image fromthe at least one encoded map image; and generating at least a portion ofthe decoded map image.
 19. The non-transitory computer readable mediumof claim 18, wherein the transient condition includes a trafficcondition or a weather condition.
 20. The non-transitory computerreadable medium of claim 18, wherein the transmission signal has lessthan a predetermined bandwidth.